If your answer is "it's not", you can probably stop reading now.

I've been thinking about the things that make Haskell interesting. Of 
course, the main one is that it's a 100% functional language (as opposed 
to an OOP/FP hybrid like Objective Camal), so if you want to see what 
functional programming is like, Haskell is the place to go. But on 
reflection, Haskell has several interesting and/or useful attributes 
which actually have little or nothing to do with functional programming.

Haskell has automatic type inference, for example. You don't *need* a 
functional language for that; you could totally do it in a normal 
language. It's just that, historically, nobody has. (I guess the sort of 
people who think about computer programs mathematically also tend to be 
the sort of people who realise that things like type signatures can be 
derived algorithmically.)

Everybody thinks that a programming language has to either have explicit 
types (Pascal, C, C++, Java, Eiffel...) or no static typing at all 
(Smalltalk, Tcl, JavaScript, every scripting language known to 
mankind...) Haskell demonstrates that there is a Third Way: static 
typing, but with the types implicit rather than explicit.

Obviously, there are times when either you NEED to be explicit - because 
the correct answer is ambiguous, because you want improved performance, 
whatever. There are also times when it's just "good style" to be 
explicit; top-level functions should usually have type signatures. But 
you don't have to write a signature for every single damned expression 
and variable you use in the entire program; the compiler will figure it out.

Another thing Haskell has is parametric polymorphism. If you write some 
code that makes data around, it shouldn't *matter* what the hell the 
type of the data is. I mean, if you don't "do" anything with it other 
than move it, what does it matter? So, for example, it should be 
possible to write a function that joins two containers together, 
regardless of what kind of element data they contain. (Obviously the 
type of the containers themselves matters, but not the type of whatever 
they contain.)

This pre-supposes that you have type-safe containers in the first place. 
In most OO languages, you just create a container of "Object", which can 
then contain anything. If you particularly want a container to contain, 
say, only Customer objects, you usually have to implement this yourself, 
by hand.

More recently, a couple of OO languages have introduced this feature 
they call "generics". Eiffel is the first language I'm aware of that did 
it, although I gather Java has it too now. What it allows you to do is 
write a class parameterised by another class; the typical case being a 
container class parameterised by the class of element it contains. (In 
Eiffel, integers and floats are classes, unlike the Java brokenness.)

The difference is that Eiffel makes this seem like some highly complex 
uber-feature that only a few people will ever need to use, in special 
circumstances. Haskell makes it trivial. Defining a parametric type 
requires barely a few keystrokes more than defining the same thing with 
no parameters.

C++ has templates, and people often compare this to generics. I'm not 
sure why. As far as I can tell, templates not even remotely similar to 
generics.

- Generics are an extension to the type system which allow the type 
checker to handle more sophisticated type signatures.

- Templates are, as best as I can tell, preprocessor macros on steriods. 
They automate the process of creating a new, seperate, class for each 
combination of parameter values. It's like copy & pasting each time you 
want a new container class, except the template preprocessor automates 
it for you. This is clearly very much more maintainable, but not the 
same as extending the type checker.

It seems that templates can also be used to do things which are 
impossible with generics (e.g., making the implementation *different* 
for certain special cases). So I'm not sure why people compare them at 
all, because they're so totally different.

Another thing Haskell has is algebraic data types. Other languages could 
have this. It probably doesn't play well with the OO method though. In 
fact, let me expand on that.

The OOP notion of classes, inheritance, substitution and so forth 
basically assumes a model where you can always extend the current class 
hierachy. For example, you initially decide what (conceptual) properties 
every widget must have and write that in an abstract class. Thereafter, 
you can always add new kinds of widget. (Or even specific kinds of 
widget, of course.) It's a system that works fairly well.

Haskell with its algebraic data types assumes that the data you're 
trying to model has a fixed, finite set of possibilities, which you can 
describe once and for all. If that sounds stupid and limiting, consider 
a binary tree. Every node in a binary tree is either a leaf node or a 
branch node. You will never, ever, need to add a new kind of node. (If 
you did, it wouldn't be a *binary tree*. It would be something else.)

So the data structure of a binary tree can be described once and for 
all. However, the operations you can perform on it is extensible; you 
can always add new operations.

Now consider the OOP case. You write an abstract "tree" class with 
concrete "leaf" and "branch" subclasses. Each time you want to do 
something new with the tree, you write an abstract method in the tree 
class and add half of the implementation to each of the two concrete 
subclasses.

In Haskell, you write one line of code which says "a tree is either a 
leaf containing an item, or a branch containing two subtrees". You then 
write as many functions as you like, which handle the leaf and branch 
cases together, in one place (not split between three places).

For a binary tree, or an abstract syntax tree, or any number of other 
simple, ridigly-defined data structures you could envisage, this 
approach is actually much better. If you're writing a compiler or 
interpretter, you don't *need* the abstract syntax tree to be 
extensible. But you probably *do* need to be able to add new program 
passes and code manipulation functions all the time. (And letting the 
data structure be parameterised is probably Very Freaking Useful. Part 
of the compiler might use strings for names, while another part might 
use some more sophisticated structure representing fully-qualified 
names, for example.)

Now let's flip this and look at widgets again. Using the ADT approach, 
you'd need a giant "widget" type capable of representing any possible 
widget. And functions that all know how to handle any possible widget. 
And the code for handling a specific widget type is scattered between 
all the widget-handling functions.

You're never ever going to need to add new functions for handling "any 
possible widget" (although you might want one for handling a *specific* 
kind of widget). But you very likely *will* want to add new types of 
widget. But, uh, you can't.

In summary:

- If you have a limited number of structures which you want to process 
in an unlimited number of ways, ADTs work best.

- If you have an unlimited number of structures which you want to 
process in a limited number of ways, a class hierachy works best.

Haskell, of course, has to go one better: Haskell has what it calls 
"classes", but really they're "interfaces". And you can add them after 
the fact. Which means you can grab a bunch of unrelated data types 
(possibly that you didn't even write) and create a single interface for 
processing them all.

The one small glitch is that Haskell demands that all types are known at 
compile-time. Which means that doing OO-style stuff where types are 
changed dynamically at run-time is a little tricky. Haskell 98 (and the 
newly-released Haskell 2010) can't do it, but there are 
widely-implemented extensions that can. It gets kinda hairy though.

Married side by side with ADTs are case expressions. Now other languages 
have case statements, but they tend to be quite feeble. In most 
languages they only work on integers; I *think* Pascal lets you use 'em 
on enumerations [but I'm not really sure]. And in C-like languages, you 
can execute multiple alternatives at once. While this is no doubt 
occasionally useful, most of the time it's just a source of 
infuriatingly hard to find bugs (i.e., you left off the "break" 
statement, so a whole bunch of code gets executed when you didn't want 
it to).

In Haskell, case expressions work on *everything*. (Everything who's 
internal structural details are in scope, anyway. These internal details 
can be hidden from client code.) What is more, they use "pattern 
matching". This powerful feature allows you to do things like determine 
whether a tree has a particular shape and pluck several deeply-burried 
substructures out of it, all in a single transparent 1-liner. For example,

   case list of
     [[x], [y,_], [z,_,_]] -> foo x y z

This checks whether "list" contains a list with exactly 3 elements, each 
of which is a sublist of length 1, 2, 3 (respectively) - and, if all 
this is the case, it fishes out the first element of each sublist and 
feeds all the data to the "foo" function. All in one easily-readble line 
of code. The alternative in Java would be something like

   if (list.length == 3)
   {
     if (list.At(0).length == 1)
     {
       int x = list.At(0).At(0);
       if (list.At(1).length == 2)
       {
         int y = list.At(1).At(0);
         if (list.At(2).length == 3)
         {
           int z = list.At(2).At(0);
           foo(x, y, z);

which is obviously a hell of a lot longer. What is more, if your Haskell 
case expression has multiple cases in it (which it usually does), 
because of the declarative form of the patterns, the compiler can 
rearrange the code so that each test need only be performed once, and 
the compiled code can proceed with the minimum number of branch 
instructions. Such things are far, far harder to do with the 
deeply-nested forest of if-statements above. (Not to mention that the 
expressions in the if-statements might actually alter the program's 
state, so changing their order may alter the program!)

Again, this probably doesn't gel too well with OOP, which states that 
each data structure ("object") should be responsible for its own 
internal substructure. In other words, you shouldn't *need* to fish out 
deeply-burried data, the intervening objects in the chain should be 
doing this for you. According to "the OO way", the only thing you should 
ever do to objects is call methods on them, not inspect them for type 
information or substructure.

But something like, say, JavaScript (which isn't really OO in the first 
place) could certainly make use of ADTs and/or pattern matching, I think.

Another big deal about Haskell is how functions are first-class. The 
fact that functions are pure makes this a really big win, but even 
without pure functions, it's still useful. (Smalltalk implements it, for 
example.) It doesn't immediately sound very interesting, but what it 
enables you to do is write a loop once, in a library somwhere, and pass 
in the "loop body" as a function.

A trivial example is a "fold". A fold takes some container (e.g., a 
list) and repeatedly applies a binary function to it. The canonical 
example is

   sum = fold (+) 0

This says that to calculate the sum of a list, you fold it using the "+" 
function, and with a starting value of 0. (This also means that the sum 
of a completely empty list is 0.) It is obvious that

   product = fold (*) 1

but there are plenty of other uses too. For example, the (++) function 
joins to lists together, and

   concat = fold (++) []

turns a list-of-lists into a single giant list. Other examples include

   minimum = fold1 min
   maximum = fold1 max

which find the minimum or maximum of a list using the binary "min" and 
"max" functions. (The "fold1" function demands that the list be 
non-empty, and doesn't require a start value.) I could go on all day, 
but it turns out almost all uniform list operations can be implemented 
as a fold of some kind.

Other languages have done this. Smalltalk is the obvious example. It has 
#do: and #collect: which are approximately equivilent to Haskell's 
"map", #select: and #reject: which are Haskell's "filter", and many 
more. Of corse, being an object-oriented language, Smalltalk makes all 
these methods work nicely for all container types, not just lists.

(Haskell hasn't copied this trick yet. At least, not in the *standard* 
libraries. It's not difficult to change container, but it's tricky to 
write code that works generically for any container.)

The other thing about first-class function is that in both Haskell and 
Smalltalk, it is utterly trivial to spawn a new thread:

   forkIO foo                                        [foo] fork

What Smalltalk doesn't do, and Haskell does, is make combining small 
functions into larger functions trivial as well. Haskell has anonymous 
"lambda functions", it has the function composition operator, it has 
curried functions, it has the dollar operator, and so on and so forth. 
All of this *could* be put into Smalltalk, or any other OO language for 
that matter. (Whether it would be efficient is a whole other matter...)

The final thing that's interesting about Haskell is the rate at which it 
changes. Haskell (or rather, GHC) implemented Software Transactional 
Memory 5 years ago. I'm not aware of any mainstream languages that have 
this yet. GHC added Data Parallel Haskell 2 years ago, and the busy PhD 
researchers are still hard at work getting it into a usable state. 
(There's even an experimental GPU backend already.) Around the same 
time, Type Families were added. (How long did it take Java to do 
Generics?) The pace of change is staggering. Lots of new and very cool 
stuff happens in Haskell first. (No doubt it will eventually all be 
stolen by lesser languages so that people still don't use Haskell itself.)

Post a reply to this message